The Original Shareware 1.1/The Original Shareware (WeMake CDs)(Volume 1.1)(CDs, Inc)(1993).iso/36/qtech527.zip/WINRUMOR.TEC

Text File | 1991-03-13 | 16KB | 330 lines

ID:WR Windows 3.0/QEMM-386 Troubleshooting - Part II
Quarterdeck Technical Note #188
by Dan Sallitt

QEMM-386 version 5.10 and later versions support Windows 3.0 in
all of its processing modes: real, standard and 386 enhanced.

The Quarterdeck Technical Notes WIN3.TEC and WIN-TRBL.TEC
describe how to run Windows 3.0 with Quarterdeck products and how
to troubleshoot difficulties that may arise between Windows 3.0
and QEMM-386 or DESQview.  Before reading this technote, you
should read both the above documents, which contain all the
substantial information that we have gathered on running Windows
3.0 with our products.  Because some Windows-related
troubleshooting problems are unusually complex, and because the
available information on the internal workings of Windows 3.0 is
still increasing, we are providing in this technote an assortment
of unproven methods of resolving conflicts with Windows 3.0.
None of the methods discussed here have been demonstrated to be
generally effective; some are no more than rumors.  We are making
this technote available for the sake of those users with
unusually difficult compatibility problems that have not been
solved by the methods outlined in WIN-TRBL.TEC.

Mouse Problems
--------------

Windows 3.0 ships with a Microsoft mouse driver; the first
shipment of Windows 3.0 included version 7.04 of the Microsoft
mouse driver.  This version should always be tried instead of
earlier versions of the Microsoft driver, some of which we
believe may not be completely compatible with Windows 3.0.  It is
possible that some of the problems between Windows and these
earlier mouse drivers may not be obviously mouse-related.  The
driver that ships with Windows 3.0 can sometimes be used even
with non-Microsoft mice, and this should certainly be tried if
there is any mousing problem.

If you are on a network, check to see if your mousing problems
occur only when your network drivers are loaded.  If this is the
case, contact the developer of the network software to see if
there is a known mousing problem with the revision of the network
drivers that you are using.  We have heard an unsubstantiated
rumor that such problems may have existed with the Novell 3.01
drivers.

If your machine has a special port for the mouse (as do the PS/2
series machines, recent Compaq machines, and many others) and you
are running Windows 3.0 in real or standard modes inside DESQview
2.3 or later versions, you may wish to try the DESQview startup
parameter /HW:74:M if you are having mousing problems.

SYSTEM.INI Statements
---------------------
Windows 3.0 can be configured by putting statements in its
various .INI files, and we have not fully explored the possible
benefits of using some of the many available statements.  Most of
the statements that can affect Windows 3.0's compatibility with
Quarterdeck products, and all of the statements that we will
discuss here, should be placed in the SYSTEM.INI file, in the
section of the file that begins with the header:

     [386Enh]

Quarterdeck Technical Support has made frequent and productive
use of the SYSTEM.INI parameters:

     DualDisplay=yes

and:

     EMMExclude=xxxx-yyyy

These parameters, if they work, should be used in preference to
the QEMM-386 EXCLUDE parameter, as they do not prevent other
programs from accessing addresses between 640K and 1024K.
EMMExclude=A000-EFFF (the largest permissible area to specify)
prevents Windows from scanning the A000-EFFF area for unused
address spaces; smaller areas, like E000-EFFF, can also be
specified.  DualDisplay=yes insures that Windows will not attempt
to use the B000-B7FF area, which often contains High RAM in use
by programs that have been loaded high by QEMM.

Other SYSTEM.INI parameters that may affect Windows'
compatibility with Quarterdeck products:

     EMMPageFrame=xxxx (tells Windows where the page frame should
     be)

     NoEMMDriver=true (disables Windows' EMM driver; not
     appropriate if any DOS application wants to use EMS in
     Windows)

     HighFloppyReads=no (may prevent undesired access of the
     E000- EFFF area - should be used with EMMExclude=E000-EFFF)

     IRQ9Global=yes (intended for floppy disk problems)

     SystemROMBreakPoint=no (needed if there is High RAM above
     F000 - may be an alternative to excluding F000-FFFF)

     ReservePageFrame=no (can be used only if no DOS applications
     use EMS - gives more conventional memory to non-EMS-using
     DOS applications)

     VirtualHDIrq=off (for use with unusual hard disks)


Other Windows Configuration Issues
----------------------------------

Windows 3.0 can be set up on many video cards to run in a
graphics resolution higher than the standard 640x480 VGA
resolution.  This should not normally be a problem with QEMM-386,
and may not even be a problem when running Windows inside
DESQview (in real or standard modes), if DESQview is able to save
and restore the video mode in question.  But in problem cases one
should always first set Windows up to use standard VGA (by using
the Windows Setup program) rather than the particular video card
in question, just to see if the problem depends on the attempt to
run in a high-resolution mode.  If Windows runs with the standard
VGA setting but not in the high-resolution mode, you may want to
investigate the driver that Windows uses to go into the high-
resolution mode.  One user with a Video 7 Fastwrite VGA card was
able to make Windows real and standard mode, in 800x600
resolution, run inside DESQview 2.3 by setting up the Windows
Change a Program menu inside DESQview to use four graphics pages
AND by using an 800x600 driver he had downloaded from Compuserve
instead of the 800x600 driver that Video 7 had provided.

Windows 3.0 can take a startup parameter /MACHINE:xxxxx to tell
Windows that the system it is running on is a machine that
Windows has some special knowledge of.  (This may produce the
same effect as the selections in the System Information\Computer
section of the Windows Setup program.) Strangely, a user on a
clone 386 with an AMI BIOS reported that the /MACHINE:TOSHIBA
parameter made it possible to run Windows enhanced mode with
QEMM- 386.

QEMM-386 Exclusions
-------------------

It is often the case that previously stable systems require an
additional exclusion on QEMM-386 to allow Windows to run in
enhanced mode.  Sometimes an EMMExclude=xxxx-yyyy statement in
the Windows SYSTEM.INI file in the [386Enh] section will have the
same effect as an exclusion on QEMM, and in this case it is
probably preferable to use the EMMExclude statement, so that
programs other than Windows can access these areas.  It is,
however, occasionally necessary to specify a larger range of
addresses with the EMMExclude statement than with the QEMM
exclude parameter, as QEMM is capable of excluding address ranges
as small as 4K.

We have heard that users of Windows enhanced mode on the Compaq
Portable 386 machines may have to put the exclusion X=B000-BFFF
on QEMM-386 if they are using the 640x400 display mode available
on these machines.  The Compaq Portable 386 also displays in CGA
mode, but most Windows users opt for the higher resolution mode.

We believe that it may sometimes be necessary to put parameters
on QEMM-386 to exclude the low addresses in conventional memory
where the Windows enhanced mode kernel loads.  To find out where
the kernel is likely to load, look at the First Meg/Overview
screen in Manifest just before you are ready to load Windows, and
note the starting address of the memory area labeled as
"Available." Windows will presumably use no more than 16K above
this address; to be safe, you may wish to exclude as much as 64K
above this address, and then lower the exclusion a bit at a time
if you get results.  For instance, if the memory area listed as
"Available" is 1CF2-9FFF, one would probably err on the side of
caution and use an exclusion like:

     X=0000-2FFF

If the available area is 0B44-9FFF, try:

     X=0000-1FFF

Such low exclusions have, on some occasions, prevented startup
problems with Windows standard mode as well as enhanced mode.

The expanded memory manager that comes with Windows, EMM386.SYS,
automatically excludes the conventional memory addresses 0000-
3FFF.  If you have a problem with Windows and QEMM-386 that does
not occur with Windows and EMM386, you may wish to put the
exclusion 0000-3FFF on QEMM-386 to see if making these low pages
mappable or unmappable constitutes the difference between the
products.  One user was unable to run his AS/400 software inside
Windows enhanced mode until he used this low exclusion.

"This Application Has Violated the System's Integrity"
------------------------------------------------------

It sometimes happens that, when running a DOS application that
uses EMS inside Windows in standard mode, Windows issues an error
message stating that the application has violated the system's
integrity and must be terminated.  We currently believe that the
low exclusions discussed in the above section on "QEMM-386
Exclusions" are the most likely solution for such problems.
Other approaches to the problem have been suggested:

1) Try using exclusions on QEMM-386 to prevent all High RAM above
the page frame, or all High RAM below the page frame.

2) If it is practical, try preventing the DOS application from
using expanded memory.

3) Try changing the Windows PIF for the DOS application so that
EMS memory is locked.  This is worth trying for any problem with
an EMS-using application inside Windows enhanced mode.

4) Check the contents of the CONFIG.SYS and AUTOEXEC.BAT file.
One occurance of the "violated system integrity" problem was
solved when a Microsoft mouse driver (for a mouse attached to a
port on an ATI VGA Wonder video card) was loaded into
conventional memory rather than into High RAM with QEMM's LOADHI
parameter.



QEMM-386 Parameters
-------------------

Various parameters to QEMM-386 have been known to overcome
problems with Windows 3.0.  See the technote WIN-TRBL.TEC for a
discussion of those parameters that have been demonstrated beyond
a reasonable doubt to have a effect on Windows problems.

Users of Compaq machines often find that the NOCOMPAQFEATURES
(NCF) parameter to QEMM-386 helps Windows enhanced to start.  The
NOCOMPAQFEATURES parameter actually disables three separate
Compaq features - the COMPAQEGAROM (CER) feature, which reclaims
address space in the E000 region normally used to shadow video
ROM into faster RAM; the COMPAQHALFROM (CHR) feature, which
reclaims the first half of the F000 region (if it is unused) from
the system ROM; and the COMPAQROMMEMORY (CRM) feature, which
reclaims 128K of top memory used to shadow the system ROM into
faster RAM.  We suspect that, in those cases in which the
NOCOMPAQFEATURES parameter helps bring Windows up, the CHR
feature is really the one that must be disabled, and that the
other two features should be restored, as in the sample QEMM-386
line below:

     DEVICE=C:\QEMM\QEMM386.SYS NCF CER CRM

It is very possible, however, that the positive effects of
disabling the CHR parameter are really a result of moving QEMM's
page frame.  It is quite common for Compaq systems with the
COMPAQHALFROM feature enabled to have a page frame at addresses
E800-F7FF, and it is fairly well established that Windows
enhanced mode, at least with its default settings, can react
poorly to a page frame that overlaps with the F000-FFFF region.
If the NCF CER CRM parameters overcome a Windows startup problem,
the user is well advised to check the location of the page frame
in this configuration, remove the NCF, CER, and CRM parameters,
and replace them with a FRAME= parameter that forces the page
frame to the address just noted.  If this FRAME= parameter solves
the Windows problem, the user gets the benefit of the 32K of
mappable address space that the CHR parameter reclaims.

We also believe that the NOTOPMEMORY (NT) parameter to QEMM-386
is sometimes necessary to run Windows enhanced mode.  This was
observed on an NCR 486 microchannel system.  It is possible that
Windows enhanced mode may under some circumstances object to an
expanded memory page frame at 9000- 9FFF, or at any location in
conventional memory.  Normally, QEMM will only put a page frame
in conventional memory if it cannot find a good home for the page
frame between 640K and 1024K, so the only way to test this
hypothesis may be to relocate any pieces of ROM or RAM that your
hardware has placed in the 640K- 1024K area in order to clear a
64K area for QEMM to use for a page frame.

System Configuration
--------------------

It is possible that Windows enhanced mode may fail when Windows
accesses its permanent swapfile (a user-installable feature that
dedicates a section of the hard disk for Windows' use when it has
run out of RAM) and there is too much conventional memory
available when Windows starts - some reports put the threshold at
592K available, others at 576K available.  A good way to check
for such a problem is to eat up some conventional memory by using
QEMM-386's BUFFERS.COM program to load additional buffers below
640K.  For instance, the command:

     C:\QEMM\BUFFERS +32

will eat up 16K of conventional memory (possibly more on systems
with unusual hard disks), and, if issued before entering Windows,
will usually push the beginning of available memory up above the
threshold that is said to cause problems for Windows.

We have heard rumors that Windows enhanced mode may sometimes
function better on some systems if system shadowing of ROM memory
into faster RAM memory is disabled in the system setup.
According to the rumor, various problems with video cards and
hard disk controllers can be attributed to conflicts between
Windows and system shadowing.  We haven't yet had time to
investigate this claim.

Another rumor is that Windows enhanced mode may not function
properly on systems with more than 12 meg of extended memory.  If
this report is true, the problem will likely show up with or
without QEMM-386, though users who increase their system memory
after QEMM-386 is installed may consider this a QEMM problem.

Several users have reported that the presence or absence of DOS's
interrupt stacks has helped Windows standard mode to come up
under QEMM-386.  Unfortunately, the reports we have received seem
to contradict each other.  One user needed to put the line
STACKS=0,0 (which disables DOS's interrupt stacks) in the
CONFIG.SYS of a Hyundai 386 before Windows standard mode would
start with QEMM present; another user reported that he had to
remove the STACKS=0.0 line from his CONFIG.SYS to run Windows
standard and QEMM together.  Occasionally it seems that there is
a three-way compatibility conflict among QEMM-386, Windows
enhanced mode, and the Ontrack disk manager DMDRVR.BIN.  Not
everyone who uses all three pieces of software experiences this
problem; it is unclear at this point whether or not the version
of DMDRVR.BIN or the type of disk controller that it is managing
makes a difference, or whether one can affect the problem by
changing the order of QEMM386.SYS and DMDRVR.BIN in the
CONFIG.SYS file.
FOR REFERENCE:

Microsoft Technical Support - [phone]

      Copyright (C) 1991 by Quarterdeck Office Systems
             * * * E N D  O F  F I L E * * *